home *** CD-ROM | disk | FTP | other *** search
- Path: cerberus.fon.sprintcorp.com!news
- From: Eric Williams <Eric.R.Williams@ksopk.sprint.com>
- Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
- Subject: Re: Will Java kill C++?
- Date: Thu, 29 Feb 1996 14:59:30 -0600
- Organization: Sprint
- Message-ID: <313613B2.136E@ksopk.sprint.com>
- References: <3134D499.653E@ix.netcom.com>
- NNTP-Posting-Host: shire.fon.sprintcorp.com
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 2.0b6a (X11; I; HP-UX A.09.05 9000/712)
- CC: williams
-
- philstep@ix.netcom.com wrote:
- >
- > I have resisted learning C++ for long time because I've considered it
- > too complex. Sure, operator overloading is powerful, but doesn't it
- > allow a programmer to essentially createhis *own* language that
- > only *he* understands? Sure, pointers are powerful, but they seem to
- > cause more problems than they solve (particularly in a competitive
- > software market, where it is important to get a product to market FAST,
- > never mind thoroughly debugging it.) I'm happy that Java strips out
- > some of the more complex aspectsof C++. But, will people dump C++ for
- > Java? I sure hope so. I can hang my hat on Java.
-
-
- Java is significantly less complex than C++, from a programmer
- perspective. Here are my thoughts on some of the issues you
- raised:
-
- 1. Operator overloading
-
- Many people think of this as a "powerful" feature. In my experience,
- operator overloading is, as you say, a way for a programmer to create
- their own language. In effect, operator overloading introduces a
- form of "shorthand notation" into C++.
-
- Is this powerful? It is intended to be *conceptually* powerful,
- allowing
- users to easily understand operations like "Complex + Complex".
- Operator
- overloading does not add significant functionality to a language,
- however.
- Overloaded operators are just methods... you can implement identical
- functionality using "regular" methods.
-
- I am glad that Java does not have this feature. Java already
- has enough complexity; the more the language avoids unnecessarity
- complexity, the more room there is for the *necessary* complexity.
-
-
- 2. Pointers
-
- Pointers in C++ are a legacy of C. They allow you to do a great many
- things..... including shooting yourself in the foot in an infinite
- variety of ways.
-
- Let's face it. Most modern programming languages have enough
- expressivity
- to allow you to write the programs you want to write. It all comes down
- to how difficult the task is in any particular language. With C/C++,
- you
- must spend a great amount of time and energy worrying about pointers:
- null pointers, un-initialized pointers, pointer arithmetic, pointers to
- stack memory, pointers to heap memory, pointers to uninitialized memory,
- pointers to de-allocated memory, pointer casting, pointers and data type
- sizes, etc.. You spend a lot of time writing pointer-safety checks and
- using tools (ObjectCenter, Purify, BoundsChecker, etc.) to verify that
- your code is not abusing pointers.
-
- Part of Java's strength lies in the fact that that the programmer does
- not have to worry about physical pointers. Pointers (references) in
- Java have no machine dependencies. You don't even have to worry
- about crashing the entire process when de-referencing a null pointer
- (you just handle the NullPointerException). A Java pointer/reference
- is either null, or it refers to an object that is guaranteed to be
- type-compatible with the reference.
-
- On the flip side, part of what make applications easy to build in any
- particular programming language are the tools and libraries available
- in that language. In this respect, Java lags way behind C/C++. The
- tools are only now starting to become available. If you adopt Java
- now, you might be faced with building many of the tools/frameworks
- that exist as off-the-shelf packages for C/C++. In many situations,
- these off-the-shelf packages will mean less overall development time
- in C/C++ vs. Java.
-
-
- 3. Memory Management
-
- You didn't touch on the issue of memory management, but I feel that
- this is one of the strongest selling points of Java. C/C++ programmers
- spend so much time chasing memory leaks.... and designing and
- re-designing their code to perform proper memory management.
-
- Explicit memory management may be efficient for some applications. It
- may also be highly practical in some realms (like real-time systems).
-
- But for the majority of applications, explicit memory management is a
- major headache. These applications become *much* easier to construct
- once the programmer is freed from the burden of explicitly managing
- memory.
-
-
- 4. Threads and Monitors
-
- C and C++ have very little to say about thread management, and less
- to say about synchronization. These are usually implemented as
- external libraries..... with different APIs on different platforms.
- Using threads and semaphores makes C/C++ applications much less
- portable and much more difficult to debug.
-
- Java, however, has a built-in threading and synchronization model.
- The Java VM deals with the platform dependencies. I recently wrote
- a multi-threaded request queue in 1/2 hour in Java, just about as
- fast as I could type it. The code is portable to all platforms the
- JVM runs on. If I were to try this in C++, it would probably have
- taken me 1 week to write the code, plus another week to port it to
- other platforms.
-
- I can't wait to see performance benchmarks for JIT compiled Java,
- using native threads, running on a multi-processor machine. You would
- probably be able to beat the performance numbers with well written
- C/C++, but then again, you could probably beat well written C/C++
- using well written assembly language. :)
-
-
-
- 5. What about Smalltalk?
-
- Everything I've mentioned so far (with the exception of *real*
- threading)
- can also be said of Smalltalk.
-
- In fact, Smalltalk is *way* ahead of Java w.r.t. many issues: JIT
- compilation, advanced graphical framework, development environments,
- toolkit availability, database connectivity, stability, market share,
- etc..
-
- Java does have the jump on Smalltalk in other areas:
-
- * There is no unity in the Smalltalk market. There are
- incompatibilites
- between the major Smalltalk environments (VisualWorks, VisualAge,
- Enfin, etc.). Java has unity, for now. And Sun is intending to
- keep it that way, by allowing the Java name to be used only for
- "compliant" implementations.
-
- * Smalltalk still has a polling model for graphical interaction. From
- what I hear, there is work going on to replace this with an event-
- driven model, but it's not here today. The Java AWT is already
- event-driven.
-
- * Smalltalk does not use native threads. Sun has already delivered
- native threading for Java/Win32. I hear that sun is working on this
- for Solaris. It would be logical to assume that Java will use
- native threading whenever possible.
-
- * Smalltalk does not yet have the byte-code security necessary for
- Internet executable content. Java was [re]designed for this.
-
- * Java has been embedded in the Netscape browser. As of today, you
- can write Applets that will execute over the Web on a Netscape
- browser. Smalltalk can not make this claim.
-
-
- For now, Smalltalk is probably a better choice for application
- development. For Internet Applet development, however, the choice
- is clear.
-
-
- The question "Will Java Kill C++?" can really be expanded to:
- "What effect will Java have on C++ and Smalltalk?"
-
- I don't know the complete answer. Java solves a number of problems
- that programmers face. If you were to attempt to build a major
- application in Java today, however, your programmers would face
- difficulties that have already been solved in C++ and Smalltalk.
-
- To further complicate the question, will Java expand from its
- niche market (Internet executable content) to become a full-fledged
- application development language? Will people take it seriously
- as such?
-
- Java has promise. But it will take time and energy to convert on
- this promise. The existing tools have to stabilize. The graphical
- library (AWT) must improve. And many, many vendors need to
- introduce commercial-quality software development tools/libraries.
- In addition, the JDBC specification must deliver secure access
- to corporate data.
-
- Java also has momentum. And along with that, media attention. Yes,
- there is a lot of hype, but that means that people are getting
- excited about the language. Nothing encourages investment in a
- technology like *continued* media attention.
-
-
- I haven't been around the computer industry long enough to predict
- with certainty what will happen, but I doubt that Java will completely
- uproot any existing language. That's just too expensive. Today's hot
- technology will become tomorrow's legacy system (supporting an entire
- arm of the consulting industry). Some development will shift gradually
- to Java, as the language stabilizes and offers more development tools.
- Will it be C++ or Smalltalk that loses more to Java? Intuitively, I
- would say that C++ will be the first to lose programmers to Java. Java
- is syntactically similar to C++, so C++ programmers easily learn Java.
- But Smalltalk will also lose programmers to Java if the major Smalltalk
- players don't address the "Internet executable content" issue.
-
- It will be an interesting next couple of years, at any rate.
-
-
- -eric
-